The ultimate goal of any business is to maximize profits. Every business relies on a set of activities or processes that allow the business to function. For example, a manufacturing business obtains raw materials and components, creates a product, and delivers that product to customers. Countless business processes within each organization carry these operations forward efficiently and profitably.
Processes can be examined at different points to provide an array of feedback to managers, e.g., at the production line or at the enterprise-wide. Frequently, processes are grouped for analysis by department or division. For example, procurement may examine the procurement processes to obtain resources and materials. Product development may examine the development processes to plan, design, and refine goods and services. Production may examine the production processes to manufacture and provide goods or services. Other areas may also examine their processes to maintain and improve efficiency and profitability, e.g., accounting, marketing, customer service, etc.
Actively managing such processes allow the identification of points of delay and inefficiencies that are invisible to the organization, e.g., eliminate flaws, reduce task time, decrease cost, etc. In addition, active process management facilitates improvement even in well-refined procedures. However, before a process can be improved, processes need to be documented. Documenting existing processes is a key step to achieving consistent quality, and it is the critical starting point of ISO and other quality certification.
Business processes may be represented as a number of potential conditions or states. At each point, the process performs a certain action, or the like, with the result or results therefrom directing the next process that needs to be performed. For any particular state, there may be more than one transition path. Moreover, there may be more than one transition path out of a state. For example, in a manufacturing environment, a loop may be involved wherein the production line produces many units of a device as a separate process. Such a loop can result in tens of processes if not hundreds.
In some instances, faults occur that result in a failure to execute the process. A failed process state refers to a fault wherein conditions for performing the process or exiting from the state are never met. For example, the process may enter a state and wait for a certain action that will never arrive. Once an occurrence of a failed process arises and is recognized, the system operator must identify and correct the cause of the failure. Sometimes the cause of the failed process may be easily discovered in the current process. Other times, the fault may be caused at a transition path selected at some point in the past. The cause of such a fault is difficult to identify because there may be a multitude of possible branches, paths and associated actions through which the process passed before the failure manifests itself. All pertinent possible combinations of states and paths and actions must then be examined in order to determine which is the cause.
To further complicate this practice, processes may involve third parties that perform a service to a manufacturer. For example, a manufacturer may sell products to a customer. The manufacturer may provide products to a third party for configuration. The third party may then ship the product to the customer after performing the third party services, e.g., configuration. At the same time, different business-to-business (B2B) standards, e.g., Electronic Data Interchange (EDI), may be used to transfer data between the third party, the manufacturer and the customer using networks, such as the Internet. Each of the B2B-type electronic signals may trigger a chain of different processes, which must be executed and managed.
Solutions for managing the processes have been developed. One such solution applies to a chain of only two processes. In this solution, the system processes the first part and the data is automatically committed by the system, e.g., SAP. Then the program performs the second part. If both parts are successful, the job is finished. If the first part fails, the whole signal can be re-processed after the problem is resolved. However, a problem occurs when the first part is successful but the second part fails. In this instance, two options are available: either rollback the first process (if possible) and reprocess the signal, or manually perform the second process. This procedure, although painful, can work for a simple two-part process.
The above procedure may be automated to provide additional efficiency. For example, when the original signal is received, the original signal is processed and the first part then creates another signal and sends to the system for the second step. If the second signal fails, then the second part can be re-processed independent of the original signal after the problem causing failure is removed. This process worked well for two steps although there is a certain amount of overhead involved with creation of the second signal. Further, it is not easy to trace back from the second signal to the first one and vice versa when was needed.
However, this procedure is not practical for a process having more than two parts. As mentioned above with reference to loops, for example, a process may produce tens of signals with each with having hundreds of additional signal associated therewith. Thus, hundreds of signals may result from each original signal. Such a large number of signals presents a large performance and storage overhead and is a very complex system to properly implement and maintain. Further, it is impossible for the user to work with this many signals because the user must navigate through many levels of different signals. Additional drawbacks include complexity in creating the signal to process the next step, creating new signals in each step takes execution time, many different signal types are required to perform each one specific process (for example create delivery), large amounts of data are provided in each signal, it is hard, if not impossible, to investigate the cause of an error and sometime the error tracing requires walking back to the first signal.
It can be seen that there is a need for a method, apparatus and program storage device for managing multiple step processes triggered by a signal.